[レポート] スプリント内で試験を完了させるには?アジャイル・スクラム開発に参加したQAエンジニアの悩みと対策 #jassttokyo

こんにちは。AWS事業本部モダンアプリケーションコンサルティング部に所属している今泉（@bun76235104）です。

私は2024年3月14日~3月15日に開催されているJaSSTソフトウェアテストシンポジウム-JaSST'24 Tokyoに参加させていただきました。

今回は聴講したセッションのうち、スプリント内で試験を完了させるには?アジャイル・スクラム開発に参加したQAエンジニアの悩みと対策について私なりの概要やおすすめだと思ったポイントについてまとめたいと思います。

講演者

• 渡邉 豊幹 氏（サイボウズ）

概要

以下はセッションの内容より引用したセッションの概要です。

私の所属するチームはアジャイル・スクラム開発を導入しています。 しかしスプリントレビューまでに試験を完了できておらず、品質について迅速にフィードバックできていない課題がありました。 そこで開発チームで課題に取り組み、スプリント内で試験を完了しフィードバックを行えるよう工夫しました。 本セッションでは、取り組みとその結果についてご紹介します。

発表資料

2024年3月14日22時45分現在では公開がないようですので、発見したら更新させていただきます。

まとめ

• 講演者は現在はモバイルアプリを担当
• 背景
  • チーム構成
    • iOS プラットフォームのチーム
    • Android プラットフォームのチーム
  • 開発プロセス自体はスクラムを採用していたが、QAがテストとかを受発注しているような感じだった
  • テスト実施が遅くなり、QAのテストがDevチームから1スプリント遅れてやっているような状態になってしまった
• 対策
  • テスト設計のコストを下げることから始めた
    • マインドマップの利用
      • これまではテスト設計の成果物はスプレッドシートを使っていた
      • 都度修正するのにコストが掛かっていた
      • 詳細な仕様をフォーマットに則って作るというコストの割に、あまりバリューを出せていないという話になった
      • テスト観点の洗い出しにマインドマップをつかうようになった
        • （私の感想）
          • フォーマットなどで疲弊するのではなく、本質的な観点などに注力するという意味だと思った
      • マインドマップのフォーマットや見方は統一した
    • モブの活用
      • テスト設計に関わっていないメンバーが容易にキャッチアップできるようにしたい
      • テスト設計自体の質を保ち、それぞれの観点などでまなびをもたらすことができるようになった
      • ただし、拘束時間は長い。ドライバーの時間をただ眺めている時間もあった。
      • 現在は個人で設計 → モブでレビューするようになった
        • すべてをモブでまかなうわけではない
  • スプリント開始前にテスト設計を前倒しで行うようにした
    • ↑のようにテスト設計のコストが下がったため、できるようになってきた
    • １バッグログで10 ~ 30分程度、全体で2~4時間かけて実施
  • デイリースクラムの中でも「スプリントゴールを達成できそうか」ということを把握し合うようにした
    • 1~5点のスコアのような形で個人ごとに言い合う形である様子
• 対策後の課題
  • プランニング時に調整・業務量を平準化できつつあるが、単純に業務量ギリギリのスプリントが続くと工数が厳しい
  • まだまだQAのエンジニアの感覚や経験に頼っている状態が続いている

感想

• リリースや開発のボトルネックになりがちがQA活動についてサイボウズさんにおける取り組みを丁寧に教えていただきました
• プロダクトを継続的にリリースするためには当然「お金と時間」に制限があるなかで、素早くQA活動を実施していくための取り組みをとても丁寧に教えていただいた
  • それでも「テスト設計にかかるコスト」ということを課題に取り込まれてそれを運用されるのはとても良い取り組みだなと感じました
• 「QAがいない組織」という方よりも「QAがいるけどリリースのボトルネックになってしまっている」という方にはすごく良いセッションだと思います
  • 各社このように悩んで、計測して、やってきたことがあると思いますが発表されているって本当に素晴らしいですよね